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1.0 INTRODUCTION 

The Runway Safety Monitor (RSM) was developed by Lockheed Martin in support of NASA’s 
Runway Incursion Prevention System (RIPS) research. This work was conducted under the 
NASA Aviation Safety Program’s Synthetic Vision System element. RSM was developed as a 
component of the Integrated Display System (IDS), an experimental avionics software system 
for terminal area and surface operations developed by Lockheed Martin [1], Under evolution 
since 1993, the IDS is the primary software for implementing RIPS functions and displays on 
board the NASA B-757 research aircraft. The RIPS research system includes the IDS RSM 
software in addition to other aircraft and ground based incursion algorithms and makes use of 
IDS data communications and displays, Global Positioning System (GPS), ground surveillance 
systems, and data links. The advanced capabilities of IDS and RSM provide pilots with 
enhanced situational awareness, supplemental guidance cues, a real-time display of traffic 
information, and warnings of runway incursions in order to reduce the possibility of runway 
incursions while also improving operational capability. The RIPS was flight tested and 
demonstrated at the Dallas/Forth Worth International Airport (DFW) during the fall of 2000 
with highly successful results [2, 4], 

A railway incursion is defined by the Federal Aviation Administration (FAA) as: “any 
occurrence at an airport involving an aircraft, vehicle, person, or object on the ground, that 
creates a collision hazard or results in the loss of separation with an aircraft taking off, 
intending to take off, landing, or intending to land.” In other words, a runway incursion occurs 
when the use of a runway results in a conflict between an aircraft taking off or landing and 
other traffic, i.e., aircraft, vehicle, person, object, that may lead to a collision or loss of 
separation. An incursion is not an accident; it is a hazardous situation that could cause an 
accident. Consequently, a runway incursion alert, as defined by RSM, is not necessarily a 
warning of an impending collision. It is a means of notifying the pilot when a hazardous 
situation on the runway (i.e., incursion) is detected so that evasive action can be taken to avoid 
an accident. 

RSM does not “prevent” incursions but detects incursions as defined above by the FAA and 
alerts the pilot via IDS visual displays and aural warnings. The “prevention” part of RIPS is 
accomplished by a suite of IDS capabilities such as heads up display (HUD), electronic moving 
map (EMM) display, cockpit display of traffic information (CDTI), taxi routing, controller hold 
bars, taxi route deviation messages, hot runway hold bars, and other features that increase the 
pilot’s situational awareness [1], Results of both the DFW flight tests and previous flight tests 
at Atlanta Hartsfield International Airport (ATL) in August of 1997 [3], verify that incursion 
situations are not likely to occur when IDS technology is employed on aircraft. However, in the 
event that IDS displays fail to provide the complete situational awareness needed to prevent an 
incursion in the first place, RSM plays an important role. The purpose of RSM is to detect the 
hazardous situation immediately and alert the pilot in sufficient time to take evasive action. 

This report documents the RSM software, and describes in detail how the RSM algorithm 
performs ran way incursion detection and alerting functions for NASA RIPS. The report 
describes the software used during the DFW flight tests and subsequent enhancements that were 
made based on results of those flight tests. The performance results and lessons learned from 
the flight tests at DFW are also described. 
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2.0 GENERAL DESCRIPTION AND CAPABILITIES 

2.1 Incursion Detection and Alerting 

The RSM was designed to run on board the NASA B-757 research aircraft as one of two 
aircraft based incursion algorithms in support of RIPS research. Although RSM currently runs 
as a component of the NASA IDS, the algorithm itself can be implemented to run as a separate 
and independent program on board any aircraft with traffic data link capability. 

RSM detects a runway incursion and issues an incursion alert when ownship (e.g., NASA B- 
757) is using a runway and there is a conflict with other traffic using the same runway. The 
underlined terms need further explanation in the way they are interpreted by RSM. Other 
traffic is defined as aircraft, vehicles, equipment or objects that can be identified by the airport 
ground surveillance system and/or Automatic Dependent Surveillance-Broadcast (ADS-B) and 
data linked to the aircraft. The term conflict is synonymous with incursion meaning there is a 
(potential) collision hazard or loss of separation when ownship, other traffic, or both are in the 
process of taking off or landing. “ Using a runway ” includes landing, taking off, or taxiing 
within the boundaries of the runway incursion zone (see 2.2 below). Intent to use a runway is 
assumed if ownship or traffic taxi across the hold short line and enter the runway incursion 
zone, even if not yet on the runway. 

An incursion is usually, but not necessarily, triggered by an error on the part of one or both 
aircraft/traffic involved, or a controller error. However, the RSM algorithm does not determine 
fault, if any; and the same alert is issued whether the incursion is the result of action by own- 
ship, other traffic or controller. RSM incursion alerts are single stage alerts. That is, only one 
type of alert, a runway conflict alert (RCA), is issued for all incursion situations that are 
detected (see 2.3 below, Incursion Scenarios). When an RCA is issued it means that an 
incursion is already in progress (not projected) and, therefore, an evasive maneuver should be 
initiated at the pilot’s discretion. Guidance for any specific evasive maneuver is not provided 
by the algorithm or the alerting system. 


2.2 Runway Incursion Zones 

A major concept of the RSM algorithm is the use of runway incursion zones. A runway 
incursion zone is a software derived three-dimensional invisible zone (not shown on displays). 
There is one incursion zone for each runway on the airport. The horizontal dimensions of a 
runway incursion zone overlay the associated runway, with the width or sides of the zone 
extending a constant distance from both sides of the runway, and length or ends of the zone 
extending a constant distance from both ends (thresholds) of the runway. The third (vertical) 
dimension of the incursion zone is a constant value for the altitude of the zone above the 
runway surface. The incursion zone boundaries and zone altitude form a long rectangular 
shaped box that defines the 3 -dimensional space where runway incursions are monitored. 
Flight operations outside of this box are not monitored for runway incursions. Figure 1 is a 
two-dimensional plan view showing runway incursion zones at the Dallas-Ft Worth airport. 
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Accurate placement of the incursion zones is critical for correct performance of the algorithm 
and prevention of false alarms. See Lessons Learned, Section 4.63.2. The coordinates for each 
railway incursion zone are computed based on information in the RSM configuration file (see 
Section 3.1) and airport database for ran way thresholds, widths, ILS glide slope angles, 
incursion zone altitude and other data. The zone altitude used for DFW was 400 feet AGL 
based on results of simulations and flight tests. The values for the sides and ends of the zones 
can vary for each railway. The sides of a zone are set to be near the hold short positions but not 
too close to set off false alarms when aircraft are stopped at the hold line. The value used for 
DFW was 220 feet from the edge of runways used during the flight tests. The ends of zones 
vary based on the intersection of the ILS glide slope path with the incursion zone altitude. 
Using a zone altitude of 400 feet and glide slope of 3 degrees places the ends of the zone at 
approximately 1 . 1 NM from the runway threshold. The width of incursion zones is wider at the 
approach ends than at the runway thresholds and appears to fan out toward the ends (see Figure 
1). This difference is due to the allowance of up to a two-dot ILS localizer deviation error on 
approaches. 

When ownship is using a ran way (see definition in 2.1 above), whether intentionally or in error, 
the positions of other traffic inside the incursion zone for that runway are continually tracked. 
Only the runway zone used by ownship is monitored for other traffic; and incursions between 
other traffic that do not involve ownship are not detected. Note that when ownship is not using 
a runway, traffic is not monitored in any runway incursion zone. Also, any possible conflict 
between ownship and other traffic outside or above the runway zones (on taxiways, non- 
approach areas, etc.) is not a runway incursion and, therefore, not monitored by this algorithm. 


2.3 Incursion Scenarios 

RSM was designed to detect all possible scenarios for runway incursions. For example, own- 
ship can be entering the runway while another aircraft is taking off or landing. Ownship can be 
landing or taking off while another aircraft/vehicle is taxiing across the runway, or construction 
equipment is located on the runway. Also, one aircraft can be landing while another is taking 
off (chase scenario), intending to take off, or not yet off the runway from a previous landing. 
Aircraft or vehicles can be lost and wander onto a runway by mistake. There are numerous 
scenarios and variations of scenarios if all the possible conditions are considered. It should be 
noted that an incursion scenario always involves at least one aircraft (ownship or another 
aircraft) in the process of taking off or landing, or intending to take off or land. See FAA 
definition of incursion in Section 1 .0, Introduction. Therefore, conflicts on the ground between 
ownship and traffic that involve taxi only operations, with no intention to take off, are not 
considered runway incursions. 

The capability to detect any type of runway incursion is accomplished using a generic approach 
since it is difficult to define and program separately for all possible incursion scenarios. The 
generic approach makes use of runway incursion zones described above and the concept of an 
operational state matrix for ownship and traffic. See Sections 3.23.3 and 3.23.4. Seven 
operational states (or phases) are defined by RSM that form a 7 by 7 matrix with 49 possible 
state combinations for ownship and traffic. Each combination of ownship state and traffic state 
in the matrix determines whether or not an incursion is possible for different incursion 
situations. If the matrix indicates an incursion is possible, validation criteria are applied to 
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determine if the incursion is valid and not a false alarm. If the validation criteria indicate no 
false alarm, an incursion alert is issued. 

The generic approach used by RSM proved to be highly effective in testing four different 
scenarios during the NASA REPS flight tests at DFW. All scenarios involved the NASA B-757 
research aircraft and a test van equipped with data links and transponders to simulate another 
aircraft. The four scenarios tested are shown in Figures 2A - 2D. Scenario 1: B-757 is landing 
on approach and test van is crossing the runway. Scenario 2: B-757 is taking off and test van is 
crossing the railway. Scenario 3: B-757 is crossing the hold short line entering the runway and 
the test van is simulating a takeoff on the runway. Scenario 4: B-757 is landing and the test 
van is simulating a takeoff on the runway (chase scenario). These scenarios and RSM 
performance results for each scenario are described in Section 4.0. 
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3.0 THE RSM ALGORITHM - TECHNICAL APPROACH 

The algorithm is programmed in the C language as a set of function calls that are encapsulated 
and integrated as a component of the IDS software. The RSM could be implemented as a 
separate program from the IDS by having its own data input files and access to traffic data from 
the ground surveillance system and/or ADS_B. However, incorporation of the RSM as 
functions within the IDS allows sharing of already existing software and database resources. 
For example, the IDS traffic monitor function provides traffic data to the RSM, and the IDS 
EMM and IDS HUD generate displays of incursion alerts issued by the RSM. The technical 
approach is described in sufficient detail to provide a complete understanding of the algorithm 
without going into the low level programming details of coding and data structures. A high 
level flow diagram for the algorithm is provided in Figure 4. 

The technical approach for RSM is straightforward. The algorithm is divided into three main 
parts. Part 1 invokes RSM and determines if runway incursion testing should be started, 
continued or terminated. Incursion testing is performed only when the ownship aircraft is using 
a runway and is inside a runway incursion zone as defined in Section 2.2 above. If incursion 
testing is performed, Part 2 of the algorithm is invoked to find and track all traffic inside the 
runway incursion zone in use and save/ verify zone traffic data. If there is no traffic inside the 
zone, the algorithm returns with no further action. Otherwise, Part 3 of the algorithm checks 
for incursions by testing all traffic in the zone using operational state criteria (the state matrix) 
and other validation criteria to prevent false alarms as described in 3.2.3 below. Part 3 does the 
most critical work of detecting any incursions and outputting the incursion alert data. 

In addition to the RSM algorithm, the IDS software includes a separate and independent 
function to process the incursion alert data output by RSM or other algorithms. This important 
function, described in Section 3.3, reads the output data from RSM or whatever incursion 
algorithm is used, processes this data to initiate or terminate the incursion alert displays and 
auditory warnings, makes data available to the IDS display generators, and initiates down link 
messages to the ground controller. 

The IDS also includes software to generate the graphical displays and auditory warnings for 
incursion alerting. The IDS display and aural formats are not part of the RSM algorithm but are 
a separate area of ongoing human factors studies to determine the best methodologies for 
providing incursion alerting and enhanced situational awareness to the flight crew. The 
displays that were used during the flight tests at DFW are shown in Figure 3. 

3.1 Incursion Detection Criteria 

Detection of incursions is based on criteria for placement of the runway incursion zones (zone 
criteria), criteria to determine operational states of ownship and traffic (state criteria) and other 
criteria to check if the incursion is valid and not a false alarm (validation criteria). The zone 
criteria are described in Section 2.2 above. The state and validation criteria are described in 
Section 3.2.3. Most criteria are computed from data available in the airport database and/or 
traffic data. However, some criteria and threshold values are defined as program constants that 
are contained in an RSM configuration file read at IDS system startup. Since threshold values 
for these criteria can vary depending on the airport conditions, ATC requirements and type of 
aircraft, the configuration file allows these values to be readily changed without recompiling the 
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software. The criteria and thresholds in the RSM configuration file for the DFW airport are 
listed below. 

CRITERIA PROGRAM NAME VALUE for DFW 


Rwy incur zone dist from rwy edge 

Rwy incur zone dist from rwy end 

Rwy incur zone altitude 

Max targets in rwy incur zone 

Dist CG to nose of AC (B-757) 

Dist CG to tail of AC (B-757) 

Min separation distance 
Max taxi speed 
Landing vertical speed 


kRwy Incur ZoneDistEdge 
kRwy Incur ZoneDistEnd 
kRwy Incur ZoneAlt 
kMaxTargets InZone 
kDistCGtoNose_ownship 
kDistCGtoTail_ownship 
kMinSeparation 
kMaxTaxi Speed 
kLandingVerti cal Speed 


220 ft 

6634 ft (-1.1NM) 
400 ft 
5 

75.0 ft 

50.0 ft 

12000 ft ( ~2 NM) 
4 5 kts 
-400 ft/min 


3.2 Algorithm Logic and Data Flow 

The logical operations and data flow of the RSM incursion algorithm are described in the 
following sections. Refer to Figure 4, RSM Algorithm - High Level Flow Diagram. Note that 
in the descriptions below, traffic will often be referred to as targets. Target is a more general 
term for anything seen by the ground surveillance system (e.g., aircraft, vehicles, construction 
objects, runway equipment, etc.) and relayed to the aircraft via data link. 


3.2.1 Algorithm Part 1: Invoking RSM 

The top level RSM function, RunwaySafetyMonitor(), is called by the traffic monitoring 
function of the IDS after each complete traffic data scan. A single traffic scan occurs 
approximately once per second based on the time for one 360 degree sweep of the Airport 
Surface Detection Equipment (ASDE-3) surface radar. In addition to ASDE-3, a Surface 
Traffic Information Service - Broadcast (STIS-B) traffic scan may include a fusion of all 
available surveillance sources such as ADS-B and multilateration. Traffic information 
collected on the ground during the previous one second interval is up linked to the aircraft and 
stored in the current traffic data list. The traffic scan rate can be increased to two hertz if only 
ADS-B is used. The current traffic data list contains a unique numeric ID, flight number/call 
sign, lat/long position, altitude, velocity, and heading data for all traffic in the scan. If there is 
no traffic or traffic data is not available to the RSM via the IDS communications software, e.g., 
data link is down, the RunwaySafetyMonitorQ function returns. 


3. 2.1.1 Start/Stop/Continue Incursion Testing 

If traffic data is available, the RunwayS afetyMonitor() determines if incursion testing should be 
started and, if so, what runway incursion zone is in use. If testing is already being performed, 
the function determines if incursion testing should be terminated. These determinations are 
made based on the ownship state conditions described below. If incursion testing is not 
required or is terminated based on the ownship state, any traffic data previously saved is cleared 
and the function returns without further action. 
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Incursion testing on the ground . If ownship is on the ground, incursion testing is 
initiated if the aircraft is found to be inside of any runway incursion zone and terminated 
if ownship exits the zone, takes off and flies outside the zone or climbs above the 
incursion zone altitude (400 ft. AGL for DFW). 

Incursion testing in the air . If ownship is airborne, incursion testing is started if the 
aircraft is on final approach to a runway and enters the approach end of the runway 
incursion zone. The distance of the approach end of the incursion zone from the runway 
threshold is computed based on the intersection of the ILS glide slope angle and the 
incursion zone altitude. For DFW this distance is 6634 feet (~1.1 NM) from the end of 
the runway based on a glide slope angle of 3 degrees and incursion zone altitude of 400 
feet. The criteria for computing ends of the incursion zones can vary for each runway at 
an airport and from one airport to another based on operational requirements. If 
incursion testing is started in the air, it is terminated when ownship lands and exits the 
incursion zone, flies outside the zone, or aborts the landing and climbs above the zone. 

Referencing the runway incursion zone . When incursion testing is started, either on the 
ground or in the air, a pointer to the specific runway incursion zone is obtained that 
provides the x,y Cartesian coordinates of the zone used for monitoring traffic. If own- 
ship enters an incursion zone on the ground, the pointer is for the runway zone that own- 
ship is entering. If ownship is airborne, the pointer is for the runway zone penetrated on 
final approach when the aircraft is lined up with the runway. Note that the runway zone 
on approach can also be obtained from the selected runway name entered by the pilot 
via the CDU. This information is made available to RSM through the IDS 
communications software and data block. A cross check is made to insure that the 
runway zone actually penetrated is the same as the runway name selected in the CDU. 
Although not currently implemented, the pilot can be notified if there is any discrepancy 
between the runway selected and the actual runway in use. 


3.2.2 Algorithm Part 2: Monitoring Traffic in the Runway Incursion Zone 

If incursion testing is required, the RSM calls TestAllTraffichiIncursionZone(). This function 
performs the primary logical operations for monitoring traffic in a zone (Part 2) and determines 
when to issue incursion alerts by testing incursion criteria (Part 3). The detailed logic is 
documented in the source code for the function, but a general synopsis is described below. 
Note that it is possible to have more than one incursion occurring at the same time in a 
monitored incursion zone. For the DFW flight test, the limit for the number of simultaneous 
incursions was set to two. 


3. 2.2.1 Finding and Tracking Targets in the Zone 

The traffic data list is obtained from the IDS and the x,y position for each target in the list is 
compared to the coordinates of the runway incursion zone (obtained via the pointer described in 

3. 2. 1.1 above). If a target is inside the zone, the data for that target is saved in a separate data 
list for zone targets (see 3. 2. 2.2 below). Targets in the zone are tracked by ICAO address or 
other unique non-zero, positive number assigned to each target and data linked to the aircraft by 
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the ground surveillance system. If the numeric ID is zero or negative, the target cannot be 
tracked using this number, but can be tracked by flight number, if available. The flight number 
is an alphanumeric string value. If neither numeric ID nor flight number is a vailable, this target 
is labeled as an unknown target in the zone. It could be a false target, or a valid target that has 
missing IDs or erroneous data. The algorithm can track only one of these unknown targets 
because there is no way to uniquely identify and store the target data. If there is more than one 
unknown target in the zone, all unknown targets are discarded. 


3. 2.2.2 Saving and Clearing Zone Traffic Data 

Saving data in the list for zone targets, the zone list, is done by checking if a target was 
previously saved and updating the zone list, or if not previously saved, looking for a free 
list/array index to save the new target. A maximum of five targets can be saved in the zone list. 
There should rarely be more than five in a single runway zone at the same time, but this 
criterion can be changed in the RSM configuration file if necessary. If a target is available in 
the traffic scan but is no longer in the incursion zone being tested, its data is cleared from the 
zone list and that index position becomes available for any new targets in the zone. 


3. 2.2.3 Testing for Data Currency 

Once all zone targets have been identified and saved or cleared, each target in the zone list is 
tested to determined if the information is still current or is left over from a previous scan and no 
longer valid. The target data is deleted from the zone list if not included in the current traffic 
scan. It may have been a false target, a data link problem, or just missed by the traffic 
surveillance system. If the non-current target is not discarded, it could be the cause of an 
incursion alert that is a false alarm. During the DFW flight tests, the software on board the 
NASA B-757 that interfaced directly with the traffic data link automatically deleted non-current 
traffic data when it was more than four seconds old. The RSM test for currency of traffic data 
insures that data deleted by the data link interface is also deleted from the incursion zone list. 


3.2.3 Algorithm Part 3: Testing For Incursions 

After tracking zone targets in Part 2, if the number of targets in the zone list is greater than zero, 
Part 3 of the algorithm starts conditional testing using operational states and validation criteria 
to determine if an incursion is in progress. Each target inside the runway incursion zone is 
tested every traffic data scan. Refer to Figure 4. 


3. 2.3.1 Computing and Smoothing Traffic Data 

The following values are computed for each target based on previous and current position: 
current distance from ownship to target, distance change in feet from previous position, closure 
rate (closing or increasing distance in feet per sec) and seconds to impact when distance is 
closing, target velocity, target heading, altitude change in feet, and target 
acceleration/deceleration. These values can only be computed after the target has been inside 
the zone for two consecutive traffic scans and are based only on altitude and positional changes. 
The altitude value for each target is read from the available traffic data. Target velocity and 
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heading are also available in the traffic data list but computed values are usually more reliable 
(see Lessons Learned, Section 4.6.2). When a target is available in the current traffic scan but 
has not been updated from the previous report, the current position is estimated (smoothed) 
based on the last known velocity, heading and time since the last update. 


3.2.3.2 Checking Altitude 

The altitude criterion is the same value established for the altitude of runway incursion zones. 
This value was set to 400 ft AGL for DFW. If a target’s altitude is above the zone altitude no 
further testing is done for the target; however its data is maintained in the zone target list and 
monitored on subsequent traffic scans in the event the target drops below the zone altitude 
criterion. 


3. 2.3.3 Determining Operational States 

Seven operational states are defined for ownship and targets that are below the zone altitude: 

- taxi state : aircraft/ vehicles taxiing or not moving and stationary objects/equipment. 

- pre-takeoff state : cleared & positioned for takeoff but before or beginning of takeoff roll. 

- takeoff roll state : ground takeoff roll in progress, not airborne. 

- climbout state : airborne climb out after takeoff roll or after aborted landing. 

- landing state : final approach airborne. 

- rollout state : ground roll out after landing or after aborted takeoff. 

- fly- thru state : flying through the incursion zone but not landing or taking off. 

The operational states for targets are based on the computations in 3.2.3. 1 above for velocity, 
acceleration/deceleration, heading, altitude and change in altitude. Determination of ownship 
state is made based on the same values plus other data available in the aircraft flight 
management system. The taxi or stationary state is based primarily on the target/ownship 
ground speed being below a defined maximum taxi speed. This speed was set to 45 knots for 
DFW flight tests but can be changed in the RSM configuration file based on ATC guidelines. 
The pre-takeoff state is determined when the aircraft is stopped or the ground speed is below 
maximum taxi speed but other criteria indicate “intent” to takeoff. That is, the aircraft is ready 
for takeoff but has not started or is just beginning takeoff roll. Currently, the pre-takeoff state 
can only be determined for ownship based on data available in the flight management system 
needed to distinguish between the taxi and the pre-takeoff states, e.g., takeoff mode and throttle 
position. Since these data are not available for traffic, the pre-takeoff state for other traffic 
cannot be determined before starting the takeoff roll. See Lessons Learned, Section 4.6.4. The 
other ground states, takeoff roll and roll out, are determined by a ground speed higher than the 
maximum taxi speed plus other factors such as accelerating or decelerating speed and track 
heading. The airborne states (climb out, landing and fly-thru) are determined by altitude, 
vertical speed, and track heading in the same direction as the runway. 

Accurate determination of states is critical for correct performance of the algorithm and 
prevention of false alarms. Therefore, the specific state criteria will be evaluated in future 
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flight tests and simulations and modified or enhanced as required. However, additional traffic 
data is needed to determine the pre-takeoff state (intent to takeoff) as described above. 


3. 2.3.4 Detecting Incursions Using the Operational States Matrix and Validation Criteria 

An incursion is considered possible based on the combination of operational states for ownship 
and the target. Refer to the operational states matrix in Figure 4. If a state combination results 
in the possibility of an incursion, i.e., a YES in the matrix, additional validation criteria are 
tested to determine if an incursion situation is valid and not a false alarm. The specific 
validation criteria can vary for different positions in the states matrix. For example, if ownship 
is in takeoff roll and a target is taxiing, the validation criterion is closing horizontal distance 
between ownship and target. But if both ownship and target are in the process of taking off or 
landing, the validation criteria include directions of movement, separation distance, and 
distance closure, hi these cases, when ownship and target directions of movement are the same, 
it is a chase situation and is an incursion if distance is less than a defined minimum separation. 
When directions of movement are opposite, it is a head-on conflict and minimum separation is 
not applicable. The following is a more detailed description of the more common types of 
incursions identified by the operational states matrix. 

o Both ownship and target in the taxi state : When both ownship and the target are taxiing or 
stationaiy, this situation is a taxi only operation. Runway incursions are not monitored for 
taxi only operations since, by definition, an incursion always involves an aircraft landing or 
taking off, or intending to land or take off. 

o Ownship in the pre-takeoff state : When ownship is either taxiing or stationary but is on the 
runway in a takeoff position just prior to starting takeoff roll, the ownship state is changed 
from taxi to pre-takeoff state. The pre-takeoff state indicates the “intent” to takeoff 
immediately. The criteria used to determine this state includes being on the runway with 
the same heading as the runway, aircraft in takeoff mode, and throttle position exceeding a 
specified value to indicate start of takeoff roll. Clearance to takeoff from the controller 
could also be used as a criterion for pre-takeoff state. This information is available within 
the EDS but is dependent on CPDLC (Controller Pilot Data Link Communications), which 
is not yet operational. 

As mentioned in 3. 2. 3. 3 above, the pre-takeoff state can only be determined for own-ship 
at the present time since the intent of other traffic camiot be known a priori. For this 
reason, the operational states matrix in Figure 4 does not include a pre-takeoff column for 
targets. Traffic must be well into the takeoff roll as indicated by speed, acceleration, etc., 
before intent to takeoff is known. This shortfall for early detection of incursions will be 
addressed in future enhancements to the algorithm. See Lessons Learned, Section 4.6.4. 

When ownship is in the pre-takeoff state, an incursion is possible for any target state. 
However, for some target states, additional validation criteria must be tested to prevent 
false alarms. If the target is taxiing or stationary, the target must be ahead of ownship in 
the takeoff path. If the test for this criterion is true, an incursion alert (RCA) will be 
generated before ownship starts the takeoff roll or very early in the takeoff roll. For 
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example, if the target happens to be stationary equipment on the runway and ownship is in 
the pre-takeoff state, the hazard would be recognized immediately and the alert would be 
issued prior to any movement that could cause a collision. If the target is in a climbout or 
fly-thru state, the validation criteria include closure, directions of movement and 
separation. However, if the target is in takeoff roll, on final approach or rolling out, the 
states matrix shows that validation criteria are not required when ownship is in pre-takeoff 
state. 

o Either ownship or target in a landing/takeoff state while the other is in taxi state : The state 
conditions in this category include combinations of ownship landing/taking off and target 
taxiing/stationary or target landing/taking off and ownship taxiing/stationary. The landing 
and takeoff states include takeoff roll, climb out, landing approach and roll out. For any of 
these conditions, if the separation between ownship and the target is decreasing over time 
(closing), an incursion is detected and an alert is issued. In addition to closing, the roll out 
state requires an additional validation criterion for minimum separation to prevent false 
alarms since the aircraft is decelerating. 

The criterion for closing distance over time (closure) is necessary to prevent false alarms 
by distinguishing non-incursion targets that are behind an aircraft on takeoff or landing. A 
positive closure indicates that the taxiing aircraft or vehicle is in the direct path of the 
aircraft taking off or landing, and is therefore an incursion. It makes no difference whether 
the one taxiing is ownship or the target. For example, if ownship is taxiing across the hold 
short line and enters the incursion zone while a target aircraft is on takeoff roll or landing, 
an incursion will be detected immediately and an alert will be generated in sufficient time 
to stop the aircraft before reaching the runway. Or, if ownship is taking off or landing and 
distance to a target in the zone is closing, an alert is generated. For example, if ownship is 
on takeoff roll and a target is crossing the runway in the takeoff path, an alert will be issued 
before the ground speed becomes too high for a rejected takeoff. And if ownship is on 
final approach an alert will be issued with sufficient lead time to abort the landing (go- 
around). All of these scenarios were tested successfully at DFW. See RSM Performance 
Results, Section 4.0. 

o Both ownship and target in the landing/takeoff state : The state conditions in this category 
include all combinations of both ownship and target taking off and/or landing. These 
situations are potential incursions since no more than one landing or takeoff operation 
should occur at any one time on the same runway. A chase situation occurs when both 
aircraft are landing or taking off in the same direction, or one is landing from behind while 
the other is taking off. To prevent false alarms for chase incursions, the validation criterion 
for minimum separation distance is also used. See Section 4. 6. 3. 3. A simulated chase 
incursion scenario was tested successfully at DFW and is described in Section 4.4. If two 
land or takeoff operations are in the opposite direction, e.g., one aircraft is taking off and 
another aircraft is landing from the opposite direction, an incursion will be detected 
immediately. However, the separation distance criterion is not needed in this case since it 
is not a chase situation. 
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o Fly- thin states : One other aircraft operational state is possible for ownship and other 

aircraft that is neither taxi nor landing/takeoff. This state is called the “fly-thru” state, for 
lack of a better word. The fly-thru state means that the aircraft is not in any taxi, takeoff or 
landing state but is airborne and is flying across the runway incursion zone below the 
incursion zone altitude. Note that an aircraft flying in the incursion zone with the same 
heading as the runway would be interpreted as a landing or takeoff , not a fly-thru state. 
The fly-thru state may be seen when rotary aircraft/helicopters fly within the airport 
boundary at low altitudes directly across runways. More often, the fly-thru state is 
observed when aircraft on final approach to a runway cross an intersecting incursion zone 
for another runway. Fly-thru states can generate incursions; however, to avoid issuing 
incursion alerts that are false alarms, additional validation criteria are used. For example, if 
ownship is taking off or landing and a target is observed inside the zone in the fly-thru 
state, an incursion alert will be issued if validation criteria indicate that the target is in 
ownship’ s takeoff path and the distance is less than the minimum separation. In this 
example, a helicopter could be crossing the runway at a low altitude immediately in front 
of the departing aircraft. Another example is when ownship is taking off and another 
aircraft on approach to a different runway crosses ownship’s runway zone near the end 
where the two zones intersect. In this case, an incursion alert may not be issued if the 
distance between aircraft is greater than the minimum separation. 


3. 2.3. 5 Crossing Runways and Land And Hold Short Operations 

Many major airports have runways that cross each other, i.e., the runway centerlines intersect, 
and this situation must be considered in testing for incursions. The RSM algorithm was 
designed to handle intersecting runways but, since the situation does not exist at DFW, the 
capability has not been tested. The approach used by RSM is to consider traffic on crossing 
runways to be either in the fly-thru or taxi state depending on whether the aircraft is in the air or 
on the ground. For example, if ownship is using a runway and other traffic crosses ownship’s 
incursion zone while taking off or landing on an intersecting runway, the crossing traffic will be 
classified as a taxi state, if on the ground, or fly-thru state if airborne. This classification can be 
made because the traffic is not taking off or landing in ownship’s zone, but in the intersecting 
zone. According to the operational states matrix, this situation would be an incursion if 
ownship is in a pre-takeoff, takeoff or landing state, and validation criteria in the matrix 
indicate a valid incursion. 

Another possible incursion situation is when ownship is using a runway and crosses the 
incursion zone of an intersecting runway. In this case, ownship is located in both zones and 
RSM is required to monitor traffic and test for incursions in two incursion zones at the same 
time. This capability is currently not available in RSM but is being developed for future 
versions of the software. 

The situation is further complicated by the possibility that land and hold short operations are in 
effect for ownship’s runway, the intersecting runway, or both. If ownship is instructed to land 
and hold short of an intersecting runway, it may not be considered an incursion when traffic on 
the intersecting runway cross ownship’s incursion zone. This would depend on ownship’s 
ability to stop the aircraft before reaching the hold short position for the crossing runway. At 
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the present time, RSM has no capability to integrate land and hold short operations (LAHSO) 
with runway incursion monitoring due to the lack of data. Future capabilities with CPDLC 
and/or traffic data may provide the necessary data for LAHSO integration. 


3.2.3. 6 Aging Incursion Alerts 

When an incursion alert is generated based on data from one traffic scan, it is possible that the 
incursion will appear to no longer exist when a subsequent traffic scan is received. This can 
happen when the traffic data are erratic and inconsistent, i.e., bad data is received on one scan 
followed by good data on the next scan. In this case, an aural and visual alert might be issued, 
then terminated, then reissued several times for the same incursion and can be very distracting 
to the pilot and crew. The RSM smoothes out this on-off alert sequence by aging the incursion 
alert for a few seconds after the incursion ends. Aging the alert has the effect that multiple 
alerts are less likely to be issued for the same incursion and only one alert will be issued unless 
there are continued problems with the data. Aging does not apply if an alert is terminated 
because either ownship or the target involved in the incursion is no longer inside the incursion 
zone or is above the incursion zone altitude. See 3. 2. 1.1 above. 


3. 2.3. 7 Setting/Clearing Incursion Alert Flags/Data 

The last task in Part 3 of the algorithm is to output data into a designated IDS memory area for 
any incursion alerts to be issued or cleared. If testing for all possible incursion conditions for a 
traffic data scan indicates an incursion is in progress, the data and flags needed for the alert 
displays are written to the IDS alert memory area. These data include the type of alert (RCA), 
target id, distance to the target and seconds to impact, if applicable. If there is no incursion, the 
IDS alert memory area is cleared. 

After outputting or clearing the incursion alert data, the RSM algorithm is finished until it is 
called again on the next traffic data scan. What remains is to actually display the alert to the 
pilot and activate the auditory voice alert in the cockpit, or to terminate an alert display that is 
already in progress. This process is handled by a separate and independent function within the 
IDS and is not part of the RSM algorithm per se. This IDS function, described in 3.3 below, 
reads the alert memory area written to by Part 3 of the algorithm and processes the alert data to 
be used by the traffic and display functions of the IDS. 


3.3 Process Incursion Alert and Display Data 

When the RSM algorithm completes, the IDS calls CheckRunwayhicursions() to process the 
incursion alert data output from RSM Part 3 and make data available for IDS graphical and 
aural displays. CheckRunwayhicursions() is a separate and independent function from RSM 
that is called approximately once per second. The function issues or terminates incursion alert 
displays by reading the alert area in IDS memory, activating or deactivating the aural (voice) 
alert in the cockpit, setting or clearing the appropriate alert flags and target data for use by the 
IDS displays, and initiating down link messages to the controller when alerts start or end. Any 
alerts already in progress are reissued by this function each time it is called. This is necessary 
because alert data, including the position of targets in the traffic list, can vary after each traffic 
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scan. After processing, the alert data is passed to the EMM, HUD and traffic functions of the 
IDS for cockpit display generation. See Figure 3 for examples of the displays used at DFW. 


The separation of alert processing and display functions from RSM is necessary to provide the 
capability to process output from different algorithms other than RSM for NASA research 
purposes. This capability was used during the flight tests at DFW to run two other algorithms 
in addition to RSM, an aircraft based algorithm developed by Rannoch Corp. and a ground 
based algorithm developed by the FAA. All three incursion algorithms ran concurrently, 
producing alerts based on different sets of criteria and writing to their own separate alert areas 
in the IDS memory. Although all three algorithms were running concurrently during the flight 
tests, only one algorithm was selected for displaying visual and aural alerts to the pilot. 
Algorithm selection was done through an interactive control program on board the B-757 prior 
to each test run. RSM was the default algorithm if no other algorithms were available or 
selected. The capability to process more than one algorithm could be a useful feature to 
provide redundancy of aircraft and ground based systems during actual flight operations. 
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4.0 RSM PERFORMANCE RESULTS AND LESSONS LEARNED 

The RSM algorithm was tested extensively during flight simulations and local flight tests 
conducted at NASA Langley Research Center, and during the RIPS flight tests and 
demonstrations at the DFW airport. All data from those tests were recorded by IDS 
communications software for playback and post analyses. Data were also recorded by the 
NASA B-757 Data Acquisition System (DAS). The specific results are summarized for each of 
the four runway incursion scenarios that were tested at DFW. See Figures 2A - 2D and Tables 
1 and 2. All scenarios involved the NASA B-757 research aircraft and a test van equipped with 
data links and transponders to simulate another aircraft. The test results for each scenario will 
be followed by a performance summary and lessons learned at DFW. 


4.1 Incursion Scenario 1 

Scenario 1 involved the B-757 landing on final approach while the test van was taxiing across 
the runway at the approach end. The evaluation pilot was expected to execute a go-around 
upon receipt of the RCA. The timing conditions varied for each test run but on average the test 
van was released to cross the hold short line, i.e., given the “go” signal, when the B-757 was 
approximately 1NM from the end of the runway. The time that the van entered the incursion 
zone after crossing the hold short line marked the start of the runway incursion. 

There were a total of 12 runs for scenario 1. RSM issued RCA’s on 1 1 of those runs, of which 
there was one late alert. The RCA was not issued on one run because ADS-B traffic data was 
not updated during the tun. The ADS-B data showed the van located off the runway and not 
moving, and therefore, was not an incursion threat. The problems with the ADS-B data were a 
major concern during the DFW flight tests. See Lessons Learned, Section 4.6.1. Of the 1 1 runs 
with available traffic data, the RCA was issued approximately 1 second after the start of the 
incursion, i.e., when the van entered the incursion zone and before the van was on the runway. 
The one late alert was issued approximately 3 - 4 sec after the van crossed the hold line due to 
traffic data not available until the test van was already on the runway. Generally at the time the 
RCA was issued, the B-757 was at an average altitude of approximately 337 feet AGL with 
sufficient lead time for a go-around to be executed. The highest altitude was 365 ft and lowest 
was 226 ft. The average separation distance between the B-757 and the van was 5738 feet with 
the range being 3426 ft to 6552 ft. The differences in the values for altitude and separation 
were caused by different timing for each test tun in releasing the van to cross the hold line. 


4.2 Incursion Scenario 2 

Scenario 2 involved the B-757 taking off while the test van was taxiing across the runway at the 
opposite end. The evaluation pilot was expected to execute a rejected takeoff (RTO) when the 
alert was received. The timing conditions varied for each test run but on average the test van 
was released to cross the hold short line when the B-757 was at approximately 70 knots into the 
takeoff roll. The time that the van entered the incursion zone after crossing the hold short line 
marked the start of the runway incursion. 
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RSM issued RCA’s on 10 of 1 1 runs for scenario 2 with no late alerts. The one run with no 
RCA issued was the result of ADS-B traffic data not being updated showing no movement of 
the van during the run. This was the same problem as in scenario 1 above. Of the ten runs 
generating RCA’s, the alert was issued, and the RTO could be executed, approximately one 
second after the start of the incursion. On average, by the time the RCA was issued, the aircraft 
had reached an average ground speed of 73 knots in the takeoff roll with sufficient time for an 
RTO to be executed. The ground speed values ranged from 62 - 92 knots. The average 
separation distance between the B-757 and the van was 10381 feet with the largest distance 
being 10644 ft and the lowest 10111 ft. The differences in the values for ground speed and 
separation were caused by different timing for each test ran in releasing the van to cross the 
hold line. 


4.3 Incursion Scenario 3 

Scenario 3 involved the B-757 taxiing across the hold short line for the active runway while the 
test van simulated an aircraft taking off by accelerating down the runway reaching a speed of 70 
knots. Upon receipt of the incursion alert, the evaluation pilot was expected to stop the aircraft. 
The timing conditions varied considerably for each test run. The goal was to release the van to 
enter the runway and accelerate to a speed of approximately 70 knots to simulate takeoff, then 
give the B-757 clearance to cross the hold line. This timing would permit the incursion alert to 
be issued as soon as the B-757 crossed the hold line and entered the incursion zone, allowing 
sufficient time to stop the aircraft before reaching the edge of the runway. This timing occurred 
in all except two of the runs for this scenario. For those two runs, the van was not released until 
after the B-757 was cleared to cross the hold line, and the aircraft was already on or at the edge 
of the runway when the van reached a speed to simulate takeoff. For this analysis, the start of 
the incursion was considered to be the time that the test van reached a ground speed of 40 knots 
or higher for the simulated takeoff roll, and the B-757 had entered the runway incursion zone. 

RSM issued RCA’s on 11 of 12 runs for this scenario with no late alerts. The run that did not 
generate the RCA was, again, the result of erroneous traffic data for the test van. This time 
TIS-B data showed two copies of the test van in different locations (see Lessons Learned, 
Section 4.6.1). For the 1 1 runs with RCA’s, the alert was issued, on average, in less than two 
seconds after the start of the incursion. The range was from 0 to 3 sec. The aircraft was 
stopped before reaching the runway in all except two luns that were not timed correctly as 
mentioned above. The average separation distance was 10053 feet ranging from 6798 ft to 
10665 ft. The differences in these values were caused by the variable timing conditions for 
each run. 


4.4 Incursion Scenario 4 

Scenario 4 involved the B-757 landing on final approach at the same time that the test van was 
simulating a takeoff by entering the runway and accelerating to a speed of 70 knots. The van 
entered the runway about mid way down from the approach end. This scenario was designed to 
simulate a chase situation where ownship is landing and another aircraft is taking off. The 
evaluation pilot was expected to execute a go-around upon receipt of the incursion alert. The 
timing conditions varied for each test run but, on average, the test van was given clearance to 


18 



cross the hold short line and enter the runway when the B-757 was approximately 1 NM from 
the runway threshold. The start of the runway incursion was the time the van entered the 
incursion zone after clearance to cross the hold short line. 

RSM issued RCA’s on 11 of 12 runs for this scenario with no late alerts. The run that did not 
generate an RCA was, again, the result of ADS-B traffic data not being updated. The van 
location in the up linked data was outside the runway incursion zone and not moving. For the 
1 1 runs generating RCA’s, the alert was issued approximately one second after the van crossed 
the hold line and entered the incursion zone. The timing to release the van when the position of 
the B-757 was 1 NM from the runway resulted in alerts being issued before the van was on the 
runway in a simulated takeoff roll. Therefore, the exact conditions to simulate a chase 
incursion scenario were not tested by the RSM algorithm. Instead, the conditions tested were 
similar to scenario 1 except the van was farther down the runway. The average altitude for go- 
around was 336 feet AGL with the highest altitude at 380 ft and lowest 229 ft. At the time of 
the RCA the average separation was 11247 feet with a range from 9296 ft to 11951 ft. The 
differences in the values for altitude and separation were caused by different timing for each 
test run in releasing the van to cross the hold line. 


4.5 Performance Summary 

During the DFW testing, a total of 47 RIPS test runs were completed by four airline captains. 
RCA’s were issued by RSM on all except four runs. There was one late alert and no false alerts 
during the RIPS test runs. However, there were four false alerts generated during non-RIPS 
runs due to data errors of multiple ownship targets. See Section 4.6.3. 1, Multiple Ownship 
Targets in the Traffic Data Scan. Of the four runs with no RCA issued, three were caused by 
non-updated ADS-B traffic data that showed no van movement, and one was the result of 
erroneous TIS-B traffic data that showed two copies of the same test van in different locations. 
Of the 43 runs that had traffic data available, the RCA’s were issued by RSM approximately 
one second after the incursion began. There was only one late alert for a scenario 1 run due to 
unavailability of traffic data until the test van was already on the runway. The timeliness of 
RSM alerts resulted in more than adequate lead time for pilots to take evasive action during the 
flight tests. For the landing approach scenarios 1 and 4, go-arounds could be executed based on 
RSM alerts when the aircraft was above 300 ft AGL and approximately 0.9 - 1.3 NM from 
touch down. For the takeoff scenario 2, RTO’s could be executed based on RSM alerts when 
the B-757 was at a ground speed between 60 - 80 knots in the takeoff roll. For scenario 3, the 
timing of RSM alerts would allow the aircraft to be stopped before reaching the edge of the 
runway or to clear the runway if already on the runway when the incursion started. 

The DFW flight test results verify that the RSM algorithm performed consistently and 
effectively in detecting all runway incursion scenarios tested. The algorithm was one hundred 
percent effective when traffic data was updated correctly during test runs, and runway conflict 
alerts were always issued by RSM immediately, providing maximum lead time for evasive 
action. Flight testing at DFW and the flight demonstrations that followed proved that the RSM 
algorithm, executing on board an aircraft with reliable and accurate traffic data, can 
significantly reduce or eliminate the safety hazards associated with runway incursions. 
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4.6 Lessons Learned 

Although algorithm performance was highly successful, there were significant problems noted 
during the flight tests that did not occur during simulations. Valuable lessons learned from 
those problems as well as the overall flight test experience at DFW can be used to further 
enhance algorithm performance and greatly reduce the possibility of failure. This section 
addresses the “lessons learned” issues that are germane to development of a comprehensive and 
viable runway incursion alerting and detection system. 


4.6.1 Traffic DatalData Link Errors 

The most significant problem noted from the analysis of flight test results was the accuracy and 
timeliness of traffic data provided via data link. The importance of reliable traffic data for 
incursion detection cannot be over emphasized and much improvement is needed in this area 
before incursion alerting systems can become fully operational. The capabilities and 
performance of any incursion algorithm is dependent on the quality of the traffic data and data 
links for accurately determining the tracking identifications, positions and operational states. 
Traffic data at DFW frequently contained errors or was not updated due to data link failure, 
thus causing missed alerts for some test runs as described in Section 4.0 above. 

Many different types of data errors occurred at DFW that were not expected or considered in 
the design of the incursion algorithm. Lessons learned from those problems resulted in 
enhancements to the algorithm including the capability to handle traffic data errors more 
effectively. For example, there were multiple copies of the test van target with the same id but 
in different locations. This error caused a problem in identifying and tracking the correct van 
data and prevented detection of the incursion on one test run. Code has been added to test for 
this eiTor and track only the version of the target data that is causing the incursion. Another 
error that could have prevented incursion detection was mistaken target identity. The flight 
number for the test van was the same as the flight number used for the NASA B-757. This 
error made the van data look like a copy of ownship’s data so it was fdtered out. Changes to 
the algorithm now detect and correct for this discrepancy. A third type of error that occurred 
frequently in the STIS-B traffic data was incorrect altitude. Altitude data for the test van often 
toggled between being on the ground and being in the air above 4000 ft MSL. This error 
caused the test van to appear to be above the incursion zone altitude threshold and, therefore, 
was not an incursion threat. The algorithm now checks for this error by comparing altitude data 
with other current and previous data. 

Some, but not all, types of errors can be checked and compensated for by the algorithm. One 
problem that the algorithm can do nothing about is the lack of regular updates to the traffic data. 
This was a frequent problem with the ADS-B 1030/1090 data link at DFW. When the updates 
were not available for an extended period, either the target appeared in the wrong location and 
was not moving, or disappeared altogether. This error was the primary cause of RCA’s not 
being issued for some of the test runs. See performance results above. This error was also the 
cause of multiple RCA’s being issued for the same incursion, i.e., alert toggling, which 
occurred on some rnns. See descriptions in Table 2. The RCA would be terminated when the 
van data disappeared and reissued when the van data reappeared, and was very distracting for 
the evaluation pilots. The only remedy to prevent this error condition is to greatly improve data 
link reliability. 
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4.6.2 Inconsistent Traffic Updates 

When regular updates for traffic data were available during the DFW testing, there was still a 
problem with inconsistent timing of the updates. Sometimes data for a particular target would 
be updated once a second and other times at different intervals greater than or less than once a 
second. Each target in the data scan had a different update time and there was no way to 
determine the exact time of update for any target. The inconsistent timing of data created 
problems in determining traffic states, smoothing the traffic positions between updates and 
accurately computing data that depend on timing such as velocity, acceleration, distance closure 
rates, seconds to potential collision, etc. 

Although traffic updates could have been much better at DFW, the timing could never be 
perfectly consistent due to the asynchronous nature of surveillance sources and data links. To 
compensate for this problem, a UTC time stamp for each target position is recommended as part 
of the regular traffic data. The position time stamps would allow more accurate computations 
and smoothing for essential data elements based on changes in position. Other advantages of 
position time stamps include the ability to calculate data latencies and the ability to determine 
when updates are missing from a data scan. However, even with time stamps, accuracy of 
computations will decrease as the interval between updates increases. Therefore, regular 
updates at least once per second are necessary for optimum performance of the algorithm. 


4.6.3 False Alarms 

False alarms, i.e., invalid incursion alerts, were a major concern at DFW because there was 
little or no time to evaluate a situation when an alert was issued and immediate action might 
have to be taken, whether the alert was valid or not. Also, false alarms cause a lack of trust in 
the alerting system and greatly reduce its effectiveness. The goal for RSM was to have zero 
false alarms. There were no false alarms during the RIPS test runs at DFW; however, four false 
alarms occurred unexpectedly in between runs that were caused by errors in the traffic data 
scan. See 4.6.3. 1 below. Based on post analyses of all flight test data at DFW, a number of 
potential causes of false alarms were identified. These causes described below include multiple 
ownship targets in the traffic data scan, placement and altitude of runway incursion zones, and 
distance separation criteria. 


4.6.3. 1 Multiple Ownship Targets in the Traffic Data Scan 

The four false alarms that occurred during the DFW flight test were cansed by several copies of 
the ownship target being up linked in a single traffic data scan. The required procedure was for 
the ground surveillance system to filter ownship target data from the various surveillance 
sources and up link only one copy of the ownship target to the aircraft. The RSM algorithm 
identified the ownship target data by the expected numeric ID and/or flight number and filtered 
out this data so it was not mistaken for a valid target. RSM expected only one ownship target 
and did not filter out the additional copies when this error occurred. The effect that showed up 
on the moving map display was the appearance of a ghost target following very close behind 
the ownship symbol. The ghost target was mistaken for a valid target at a distance less than the 
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minimum separation, causing an incursion alert to be triggered. The alert was not transmitted 
to the cockpit so the pilot was not aware that a false alarm was occurring. 

The obvious solution to this problem is to prevent multiple ownship targets from being up 
linked in a traffic data scan. This can be easily corrected by the ground surveillance system. 
Nevertheless, the RSM algorithm has been modified to filter out all copies of ownship that can 
be identified so it is unlikely this situation would be problem. The only time it could be a 
problem is if the ownship target data has an incorrect or missing ID so it cannot be identified. 
This error can only be corrected by a more robust ground surveillance system. 


4.6.3. 2 Placement and Altitude of Runway Incursion Zones 

A major factor for RSM in preventing false alarms is the correct placement of the runway 
incursion zone in relation to the edges of the runway and the approach ends of the runway as 
well as the correct height/altitude of the zone. The 3-dimensional box that represents the 
incursion zone defines the space where RSM monitors incursions. Incursions are defined by 
the FAA as: “any occurrence at an airport involving an aircraft, vehicle, person, or object on 
the ground, that creates a collision hazard or results in the loss of separation with an aircraft 
taking off, intending to take off, landing, or intending to land.” See Section 1.0, Introduction. 
However, the FAA definition does not spell out what constitutes a “collision hazard”; and “loss 
of separation” is dependent on type of aircraft and many other factors. The meaning of these 
terms must be interpreted by the algorithm for each combination of operational states between 
ownship and traffic. This is done in part by defining the placement and altitude of the incursion 
zone. These specifications and the rationale for them are described in the following sections. 
Refer to Figure 1 . 

Runway Incursion Zone - Sides . The sides of the incursion zone are placed near the 
position of hold short lines for the runway since crossing a hold line could create a 
collision hazard if traffic intends to enter the runway. However, if the zone line is too 
close to the hold line position, a false alarm could occur when traffic inadvertently 
moves over the hold line and into the zone with no intention to enter the runway. Also, 
if there is a position error in the traffic data, the aircraft/veliicle could appear to be over 
the hold line when it is actually stopped behind the line. 

A single value for the zone edge distance, 220 feet, was used during the DFW flight test 
for all incursion zones, and this distance worked well for the runways used during the 
test. However, this distance would not be good for all runways at DFW where some 
hold lines are less than 220 feet from the runway. False alerts would always be 
generated for these shorter distance hold lines because the lines are inside the incursion 
zone. It is possible to set zone distance values for every hold short position; but since 
one runway can have hold lines at many different positions, the incursion zone would be 
multi sided rather than rectangular. Also, an extensive database would be required to 
match every exact hold line position on every runway for large airports, and the hold 
lines are subject to change. 
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The lesson learned from DFW is to specify a generic zone edge distance for each 
railway rather than a single generic value for the entire airport. The zone edge value for 
a specific railway should be less than the shortest distance to the hold line for that 
railway, and should take into consideration possible errors in the traffic data for 
latitude/longitude positions. RSM was modified to incorporate this approach after the 
DFW flight test. The zone edge distances for each runway were included in the RSM 
configuration data for the airport and, thus, can be modified as required when hold lines 
change or to optimize performance. For example, the zone edge distances were changed 
to 180 feet for some runways at DFW to prevent false alarms caused by the original 
zone distance of 220 feet being too wide. 

If the incursion zone edge line is closer to the runway than the hold line, the incursion 
will not be detected immediately when traffic crosses the hold line. This can be good or 
bad depending on how the definition of incursion is interpreted. The difficult question 
to answer is where the zone line should be from the edge of the runway. What exact 
distance from the runway is considered a collision hazard? It might depend on the type 
of aircraft or other undetermined factors and should be the subject of further study and 
standardization. Currently, RSM places the zone edge line approximately 40 feet closer 
to the railway edge than the hold line with the shortest distance for that runway. Post 
analyses of DFW data show this zone position causes only about a one second delay in 
issuing the incursion alert after moving traffic crosses the hold line. This delay is an 
acceptable tradeoff since the alert is still issued with adequate lead time, and the chance 
of false alarms is significantly reduced. 

Runway Incursion Zone - Ends . The ends of the incursion zone are placed at a 
specified distance from both approach ends of the runway. This distance is determined 
by calculating the position where the glide slope path intersects the runway incursion 
zone altitude. It is approximately 1.1 NM from the runway thresholds based on a glide 
slope angle of 3 degrees and incursion zone altitude of 400 ft AGL. At this distance, 
an aircraft on final approach is already cleared to land and, therefore, a collision hazard 
exists if other traffic is on or near the runway, i.e., inside the runway incursion zone. If 
traffic is detected, however, there is adequate time and altitude to abort the landing by 
executing a go-around and avoid a collision. If the end of the incursion zone is closer to 
the threshold, there is less time and lower altitude for the go-around procedure. On the 
other hand, placing the end of the zone further from the threshold could produce false 
alarms, e.g., if previously landing aircraft have not cleared the runway. An 
enhancement was made to RSM after the DFW flight test to consider possible ILS 
localizer deviation errors of up to two dots on final approach. This change results in a 
gradual widening of the incursion zone toward the approach ends. See Figure 1 . 


Runway Incursion Zone - Altitude . The FAA definition of incursion does not define a 
maximum altitude above ground level (AGL) over the railways and approach areas 
below which a traffic conflict would be considered a railway incursion. The algorithm 
defines this maximum altitude by the height of the incursion zone. The value used for 
DFW was 400 feet AGL. This height defines the approach ends of a railway incursion 
zone by intersecting the glide slopes approximately 1 . 1 NM from the runway thresholds. 
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See previous paragraph. Based on DFW performance, a zone height/altitude of 400 feet 
appears to be optimal for both early detection of incursions and prevention of false 
alarms. The value can be changed in the RSM configuration file based on different 
airport conditions and requirements. An enhancement to RSM allows each runway to 
have a different value for the incursion zone altitude, which may be desirable due to 
local conditions, terrain, etc. 


4.6.3.3 Separation Distance 

The FAA definition also includes “loss of separation” as a criterion for incursions. This 
criterion implies that distance should be considered in incursion detection. Since there are 
differences in aircraft separation requirements for various operational conditions and aircraft 
classes, the algorithm has to determine what, if any, separation criteria should be applied. 
Using the wrong separation distance for specific conditions could trigger false alerts, or could 
delay or prevent alerts that should be issued. For DFW flight tests, a single generic value of 
12,000 feet was used for all incursion scenarios. If separation was greater than 12,000 ft, an 
incursion alert would not be generated. This criterion was satisfactory for the carefully 
controlled scenarios flight tested at DFW. 

Analysis of flight test data shows that, if the runway incursion zone is defined correctly as 
discussed above, separation distance is not required for some incursion scenarios and may even 
cause a delay or failure to detect valid incursions. For example, a separation criterion is not 
recommended if an aircraft is in a takeoff roll and another aircraft or vehicle is crossing the 
runway at any distance in front of the aircraft taking off. In this case, a separation criterion may 
cause the incursion alert to be issued too late for a rejected takeoff. Another example is if an 
aircraft/ vehicle taxies onto an active runway while an aircraft is on final approach. A minimum 
separation threshold could cause the incursion alert to be missed or delayed, possibly too late to 
abort the landing. However, if the landing aircraft has already touched down and is rolling out, 
a separation criterion may be appropriate because the aircraft is decelerating and not considered 
a collision hazard unless separation is less than some minimum requirement. Also, the 
separation criterion is appropriate for chase situations when one aircraft is landing and one is 
taking off in the same direction, or both aircraft are landing, with less than minimum separation. 

There are other incursion scenarios where the use or non-use of separation criteria is a gray 
area. Further study is needed to determine the standards for using separation criteria to detect 
incursions and, if used, what the separation value(s) should be. The minimum separation 
criterion used at DFW was effective for the incursion scenarios tested. However, this value 
may be adjusted or additional values added based on future flight tests and/or simulations that 
include other scenarios with variable day/night and visibility conditions. 


4.6.4 Other Traffic - Intent to Take Off 

Again referring to the FAA definition of incursion in 4.6.2 above, an important, albeit vague, 
aspect of the definition is the reference to aircraft “intending to take off, ... or intending to 
land”. The capability exists to determine ownship’s intent to take off by data in the flight 
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management system such as heading in direction of runway, takeoff mode switch and throttle 
position. Ownship’s intent to land can be determined by altitude, vertical speed, heading, etc. 
Intent of other traffic to land can be determined in the same way. However, for purposes of the 
RSM algorithm, “intent” of other traffic to take off cannot be determined before the takeoff roll. 
There is currently no data available for RSM to determine when an aircraft is taking off until 
the aircraft is well into the takeoff roll using standard data such as velocity, acceleration, 
heading, etc. Waiting until takeoff roll will be too late in some incursion situations and there 
will not be adequate time to respond. The capability to determine intent to takeoff before 
starting takeoff roll, or very early in the takeoff roll, is critical for incursion detection by 
allowing the incursion alert to be issued prior to any movement that could cause a collision. 
The current lack of this capability is a shortcoming that can only be resolved by obtaining 
additional information for traffic that could indicate takoff intent. The specific data needed is 
uncertain at this time and should be addressed in future requirements for traffic data. 


4.6.5 Reference Point for Traffic Positions 

The reference point for a traffic position is the exact location of an aircraft or vehicle’s position 
in reference to some point such as the nose, tail or center of gravity (CG). Since there is a 
broad range in the size of aircraft and vehicles from a few feet to over 150 feet, knowing the 
exact reference point for the traffic position is highly important. The reference point is used to 
determine when traffic is inside or outside of the runway incursion zone. For large aircraft we 
would like to know when the nose of the aircraft crosses a hold line and enters the incursion 
zone, and when the tail of the aircraft is completely off the runway. However, this capability is 
currently not possible because the reference point for traffic position is not at a standard 
location. Under cun'ent procedures, the reference point can be at different locations for every 
aircraft, vehicle or obstacle in the traffic data list depending on the surveillance source. A 
significant enhancement to traffic data is needed to standardize the reference point to a known 
location, such as the CG or centrum, so the nose and tail positions can be accurately 
determined. The lack of this capability can result in incorrect timing of the algorithm in issuing 
and/or terminating incursion alerts. 


4.7 Future Research and Development 

Performance results and post analyses of data from the DFW flight test verify that the algorithm 
has the potential to significantly improve runway safety by early detection and alerting of 
runway incursions. However, the system was not tested under all possible incursion scenarios, 
or in all weather and visibility conditions. More work is needed to test and fine tune the system 
under all conditions. 

There is also a need for outside guidance and standardization to clarify the definition of runway 
incursion under all conditions. As mentioned previously in this report, there are gray areas in 
what constitutes an incursion versus a false alarm. How close to the runway is considered a 
collision hazard and, thus, an incursion, i.e., where should the edge of the incursion zone be? 
What altitude above the runway and approach zone is considered the upper boundary for 
runway incursions? What and how should separation distance(s) be applied in testing for 
incursions? These, and other, issues should be clarified; however, the important NASA RIPS 
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research, past and future, will provide valuable input for the standards and requirements that are 
needed to drive the design and development of runway incursion alerting systems. 

Further assessment of NASA’s RIPS, including RSM, other incursion algorithms, alerting 
methodologies and formats, is continuing with full mission flight simulations at Langley 
Research Center. RIPS will be evaluated under additional scenarios and visibility conditions 
not tested at DFW. RSM will also be evaluated using a computer model of all possible conflict 
scenarios. 
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Figure 3 - Incursion Alerting Displays Used at DFW 




Figure 4 - RSM Algorithm - High Level Flow Diagram 
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Validation Criteria: 

(1) Distance Closing. (2) In takeoff or landing path. (3) Distance less than minimum separation. 

(4) Ownship & target takeoff/landing in same direction and distance less than minimum separation. 

(5) Ownship & target takeoff/landing in opposite direction and closing. (6) Taxi/stationary on/near runway. 
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Table 1 - Overall RSM Performance Results For DFW Flight Test 



Total Number of Test Runs 


Num Runs With No RCA 


Num Runs With Late RCA’s 


Cause of Missing/Late Alerts 


Scenario 1 

Scenario 2 

Scenario 3 

Scenario 4 

12 

11 

12 

12 



ADS-B not 
updated. 
STIS-B not 
available 


ADS-B not 
updated 


STIS-B 

errors 


ADS-B not 
updated 


RCA Start Time - Avg 
(secs after start of incursion) 

0.99 sec 

1.0 sec 

1.45 sec 

RCA Start Time (earliest) 

0.96 sec 

1.0 sec 

0.0 sec 

RCA Start Time (latest) 

1.02 sec 

1.02 sec 

3.0 sec 


1.09 sec 


.96 sec 


1.98 sec 


B-757 Alt AGL at RCA - Avg 
(for go-around) 

337 ft 

NA 

NA 

336 ft 

B-757 Alt AGL (highest) 

365 ft 

NA 

NA 

380 ft 

B-757 Alt AGL (lowest) 

226 ft 

NA 

NA 

229 ft 


B-757 Gmd Spd at RCA - Avg 
(for rejected takeoff) 

NA 

73 kt 

NA 

NA 

B-757 Gmd Speed (lowest) 

NA 

62 kt 

NA 

NA 

B-757 Gmd Speed (highest) 

NA 

92 kt 

NA 

NA 


Separation Dist. at RCA - Avg 

5738 ft 

10381 ft 

10053 ft 

11247 ft 

Separation Dist. (highest) 

6552 ft 

10644 ft 

10665 ft 

11951 ft 

Separation Dist. (lowest) 

3426 ft 

10111 ft 

6798 ft 

9296 ft 


Total Number of Test Runs 

47 

Total Number of Runs with RSM Alerts 

43 

Total Number of Runs with Late Alert s 

1 
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Table 2 - RSM Performance Results By Run For DFW Flight Test 
























































10/17 R- 171 21 S3 AT RIAAS Y N Van not released to enter rwy until after AC crossed hold 

line. Alert issued when van reached takeoff roll speed just 
as AC was entering rwy. 


















































































Date Flight Test Scenario Traffic System RCA RCA 

# Matrix Data Displayed Issued Late Description 

Run # (RSM) (RSM) 



takeoff roll, dist 10457 ft, 95 sec. 

10/18 R172B 42 S2 T GBS Y N Alert timing 1 sec after data has van in zone. AC at 82 kts 

takeoff roll, dist 10166 ft, 74 sec. Late release of van to 
enter rwy when AC at 82 kts. 
















































































































Date Flight Test Scenario Traffic System RCA RCA 

# Matrix Data Displayed Issued Late Description 

Run # (RSM) (RSM) 



takeoff roll, dist 10350 ft, 95 sec. 

10/20 R174 65 S3 AT GBS Y N Alert issued just after AC crossed hold line and prior to 

entering runway. Data gaps and changing ID’s caused 

alert toggling. 



















































































































Date Flight Test Scenario Traffic System RCA RCA 

# Matrix Data Displayed Issued Late Description 

Run # (RSM) (RSM) 



10/20 R174 64 S2 AT RIAAS Y N Alert timing 1 sec after data has van in zone. 

AC at 62 kts takeoff roll, dist 10644, 108 sec. 
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